今日主題：

在真的進入架構的學習前，回顧一下。
我們學了好多種「元件建立原則」，像是在玩積木的規則。
這些規則讓我們的程式世界可以穩穩地蓋高樓，而不會一下子就倒掉。

範例故事：

想像你在玩一大桶積木，要蓋一座「AI 城堡」。

• REP 原則（共同重複使用原則）：相同形狀的積木要放在一起，這樣不用一直找。

• CCP 原則（共同封閉原則）：會一起改動的積木要排在同一堆，才不會東一塊西一塊亂掉。

• CRP 原則（共同重用原則）：不需要一起用的積木，不要硬塞在同一堆，免得搬不動。

• SDP 原則（穩定依賴原則）：最底層的基座要用穩固的積木，這樣上面才不會歪。

• SAP 原則（穩定抽象原則）：積木要有彈性，可以換不同顏色或造型，整體還是能用。

• ADP 原則（依賴反向原則）：把新奇但不穩定的積木放外圍，核心用可靠的積木保護。

這樣慢慢堆，才會蓋出一座結實又漂亮的城堡。

在程式中的應用是什麼？

用簡單的程式片段描述每個不同案例：

• REP（共同重複使用原則）

  // 常數集中管理
  export const PI = 3.14159; 
  export const TAX_RATE = 0.05;
  // 任何地方要用都從這裡匯入，避免重複寫
  

• CCP（共同封閉原則）

  // Blog 模組：文章和評論常常要一起修改，就放在同一個元件裡
  class BlogService {
    createPost() { /* ... */ }
    addComment() { /* ... */ }
  }
  

• CRP（共同重用原則）

  // 不要把完全不同用途的功能綁死在一起
  // 錯誤做法：把「登入」和「圖片壓縮」寫在同一個檔案
  

• SDP（穩定依賴原則）

  // 基礎工具函式 (很穩定)
  export function formatDate(date) { /* ... */ }
  
  // 上層功能 (依賴基礎工具)
  import { formatDate } from './utils';
  console.log(formatDate(new Date()));
  

• SAP（穩定抽象原則）

  // 抽象的介面 (像插座)
  class AIModel {
    generate(text) {}
  }
  
  // 不同模型可以替換
  class GPTModel extends AIModel { generate(text) { /* ... */ } }
  class GeminiModel extends AIModel { generate(text) { /* ... */ } }
  

• ADP（依賴反向原則）

  // 不要讓核心直接依賴外部 API
  // 用「介面」轉接，外圍可以自由替換
  class PaymentProvider {
    pay(amount) {}
  }
  
  class StripeProvider extends PaymentProvider { pay(a) { /* ... */ } }
  class PaypalProvider extends PaymentProvider { pay(a) { /* ... */ } }
  

就像玩積木，我們的程式世界會因為這些規則更好玩、更安全。

小結與一個思考問題：

元件的設計就像積木遊戲，有了規則才能蓋出漂亮又耐用的城堡。

思考問題：

如果你有一桶「會發光的積木」，你會把它放在核心，還是外圍？為什麼？